home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1766 < prev    next >
Text File  |  1995-07-26  |  17KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Alvestrand
  8. Request for Comments: 1766                                       UNINETT
  9. Category: Standards Track                                     March 1995
  10.  
  11.  
  12.                 Tags for the Identification of Languages
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document describes a language tag for use in cases where it is
  25.    desired to indicate the language used in an information object.
  26.  
  27.    It also defines a Content-language: header, for use in the case where
  28.    one desires to indicate the language of something that has RFC-822-
  29.    like headers, like MIME body parts or Web documents, and a new
  30.    parameter to the Multipart/Alternative type, to aid in the usage of
  31.    the Content-Language: header.
  32.  
  33. 1.  Introduction
  34.  
  35.    There are a number of languages spoken by human beings in this world.
  36.  
  37.    A great number of these people would prefer to have information
  38.    presented in a language that they understand.
  39.  
  40.    In some contexts, it is possible to have information in more than one
  41.    language, or it might be possible to provide tools for assisting in
  42.    the understanding of a language (like dictionaries).
  43.  
  44.    A prerequisite for any such function is a means of labelling the
  45.    information content with an identifier for the language in which is
  46.    is written.
  47.  
  48.    In the tradition of solving only problems that we think we
  49.    understand, this document specifies an identifier mechanism, and one
  50.    possible use for it.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Alvestrand                                                      [Page 1]
  59.  
  60. RFC 1766                      Language Tag                    March 1995
  61.  
  62.  
  63. 2.  The Language tag
  64.  
  65.    The language tag is composed of 1 or more parts: A primary language
  66.    tag and a (possibly empty) series of subtags.
  67.  
  68.    The syntax of this tag in RFC-822 EBNF is:
  69.  
  70.     Language-Tag = Primary-tag *( "-" Subtag )
  71.     Primary-tag = 1*8ALPHA
  72.     Subtag = 1*8ALPHA
  73.  
  74.    Whitespace is not allowed within the tag.
  75.  
  76.    All tags are to be treated as case insensitive; there exist
  77.    conventions for capitalization of some of them, but these should not
  78.    be taken to carry meaning.
  79.  
  80.    The namespace of language tags is administered by the IANA according
  81.    to the rules in section 5 of this document.
  82.  
  83.    The following registrations are predefined:
  84.  
  85.    In the primary language tag:
  86.  
  87.     -    All 2-letter tags are interpreted according to ISO standard
  88.          639, "Code for the representation of names of languages" [ISO
  89.          639].
  90.  
  91.     -    The value "i" is reserved for IANA-defined registrations
  92.  
  93.     -    The value "x" is reserved for private use. Subtags of "x"
  94.          will not be registered by the IANA.
  95.  
  96.     -    Other values cannot be assigned except by updating this
  97.          standard.
  98.  
  99.    The reason for reserving all other tags is to be open towards new
  100.    revisions of ISO 639; the use of "i" and "x" is the minimum we can do
  101.    here to be able to extend the mechanism to meet our requirements.
  102.  
  103.    In the first subtag:
  104.  
  105.     -    All 2-letter codes are interpreted as ISO 3166 alpha-2
  106.          country codes denoting the area in which the language is
  107.          used.
  108.  
  109.     -    Codes of 3 to 8 letters may be registered with the IANA by
  110.          anyone who feels a need for it, according to the rules in
  111.  
  112.  
  113.  
  114. Alvestrand                                                      [Page 2]
  115.  
  116. RFC 1766                      Language Tag                    March 1995
  117.  
  118.  
  119.          chapter 5 of this document.
  120.  
  121.    The information in the subtag may for instance be:
  122.  
  123.     -    Country identification, such as en-US (this usage is
  124.          described in ISO 639)
  125.  
  126.     -    Dialect or variant information, such as no-nynorsk or en-
  127.          cockney
  128.  
  129.     -    Languages not listed in ISO 639 that are not variants of
  130.          any listed language, which can be registered with the i-
  131.          prefix, such as i-cherokee
  132.  
  133.     -    Script variations, such as az-arabic and az-cyrillic
  134.  
  135.    In the second and subsequent subtag, any value can be registered.
  136.  
  137.    NOTE: The ISO 639/ISO 3166 convention is that language names are
  138.    written in lower case, while country codes are written in upper case.
  139.    This convention is recommended, but not enforced; the tags are case
  140.    insensitive.
  141.  
  142.    NOTE: ISO 639 defines a registration authority for additions to and
  143.    changes in the list of languages in ISO 639. This authority is:
  144.  
  145.          International Information Centre for Terminology (Infoterm)
  146.          P.O. Box 130
  147.          A-1021 Wien
  148.          Austria
  149.          Phone: +43 1  26 75 35 Ext. 312
  150.          Fax:   +43 1 216 32 72
  151.  
  152.    The following codes have been added in 1989 (nothing later): ug
  153.    (Uigur), iu (Inuktitut, also called Eskimo), za (Zhuang), he (Hebrew,
  154.    replacing iw), yi (Yiddish, replacing ji), and id (Indonesian,
  155.    replacing in).
  156.  
  157.    NOTE: The registration agency for ISO 3166 (country codes) is:
  158.  
  159.          ISO 3166 Maintenance Agency Secretariat
  160.          c/o DIN Deutches Institut fuer Normung
  161.          Burggrafenstrasse 6
  162.          Postfach 1107
  163.          D-10787 Berlin
  164.          Germany
  165.          Phone: +49 30 26 01 320
  166.          Fax:   +49 30 26 01 231
  167.  
  168.  
  169.  
  170. Alvestrand                                                      [Page 3]
  171.  
  172. RFC 1766                      Language Tag                    March 1995
  173.  
  174.  
  175.    The country codes AA, QM-QZ, XA-XZ and ZZ are reserved by ISO 3166 as
  176.    user-assigned codes.
  177.  
  178. 2.1.  Meaning of the language tag
  179.  
  180.    The language tag always defines a language as spoken (or written) by
  181.    human beings for communication of information to other human beings.
  182.    Computer languages are explicitly excluded.
  183.  
  184.    There is no guaranteed relationship between languages whose tags
  185.    start out with the same series of subtags; especially, they are NOT
  186.    guraranteed to be mutually comprehensible, although this will
  187.    sometimes be the case.
  188.  
  189.    Applications should always treat language tags as a single token; the
  190.    division into main tag and subtags is an administrative mechanism,
  191.    not a navigation aid.
  192.  
  193.    The relationship between the tag and the information it relates to is
  194.    defined by the standard describing the context in which it appears.
  195.    So, this section can only give possible examples of its usage.
  196.  
  197.     -    For a single information object, it should be taken as the
  198.          set of languages that is required for a complete
  199.          comprehension of the complete object. Example: Simple text.
  200.  
  201.     -    For an aggregation of information objects, it should be taken
  202.          as the set of languages used inside components of that
  203.          aggregation.  Examples: Document stores and libraries.
  204.  
  205.     -    For information objects whose purpose in life is providing
  206.          alternatives, it should be regarded as a hint that the
  207.          material inside is provided in several languages, and that
  208.          one has to inspect each of the alternatives in order to find
  209.          its language or languages.  In this case, multiple languages
  210.          need not mean that one needs to be multilingual to get
  211.          complete understanding of the document. Example: MIME
  212.          multipart/alternative.
  213.  
  214.     -    It would be possible to define (for instance) an SGML DTD
  215.          that defines a <LANG xx> tag for indicating that following or
  216.          contained text is written in this language, such that one
  217.          could write "<LANG FR>C'est la vie</LANG>"; the Norwegian-
  218.          speaking user could then access a French-Norwegian dictionary
  219.          to find out what the quote meant.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Alvestrand                                                      [Page 4]
  227.  
  228. RFC 1766                      Language Tag                    March 1995
  229.  
  230.  
  231. 3.  The Content-language header
  232.  
  233.    The Language header is intended for use in the case where one desires
  234.    to indicate the language(s) of something that has RFC-822-like
  235.    headers, like MIME body parts or Web documents.
  236.  
  237.    The RFC-822 EBNF of the Language header is:
  238.  
  239.     Language-Header = "Content-Language" ":" 1#Language-tag
  240.  
  241.    Note that the Language-Header is allowed to list several languages in
  242.    a comma-separated list.
  243.  
  244.    Whitespace is allowed, which means also that one can place
  245.    parenthesized comments anywhere in the language sequence.
  246.  
  247. 3.1.  Examples of Content-language values
  248.  
  249.    NOTE: NONE of the subtags shown in this document have actually been
  250.    assigned; they are used for illustration purposes only.
  251.  
  252.    Norwegian official document, with parallel text in both official
  253.    versions of Norwegian. (Both versions are readable by all
  254.    Norwegians).
  255.  
  256.       Content-Type: multipart/alternative;
  257.              differences=content-language
  258.       Content-Language: no-nynorsk, no-bokmaal
  259.  
  260.    Voice recording from the London docks
  261.  
  262.       Content-type: audio/basic
  263.       Content-Language: en-cockney
  264.  
  265.    Document in Sami, which does not have an ISO 639 code, and is spoken
  266.    in several countries, but with about half the speakers in Norway,
  267.    with six different, mutually incomprehensible dialects:
  268.  
  269.       Content-type: text/plain; charset=iso-8859-10
  270.       Content-Language: i-sami-no (North Sami)
  271.  
  272.    An English-French dictionary
  273.  
  274.       Content-type: application/dictionary
  275.       Content-Language: en, fr (This is a dictionary)
  276.  
  277.    An official EC document (in a few of its official languages)
  278.  
  279.  
  280.  
  281.  
  282. Alvestrand                                                      [Page 5]
  283.  
  284. RFC 1766                      Language Tag                    March 1995
  285.  
  286.  
  287.       Content-type: multipart/alternative
  288.       Content-Language: en, fr, de, da, el, it
  289.  
  290.    An excerpt from Star Trek
  291.  
  292.       Content-type: video/mpeg
  293.       Content-Language: x-klingon
  294.  
  295. 4.  Use of Content-Language with Multipart/Alternative
  296.  
  297.    When using the Multipart/Alternative body part of MIME, it is
  298.    possible to have the body parts giving the same information content
  299.    in different languages. In this case, one should put a Content-
  300.    Language header on each of the body parts, and a summary Content-
  301.    Language header onto the Multipart/Alternative itself.
  302.  
  303. 4.1.  The differences parameter to multipart/alternative
  304.  
  305.    As defined in RFC 1541, Multipart/Alternative only has one parameter:
  306.    boundary.
  307.  
  308.    The common usage of Multipart/Alternative is to have more than one
  309.    format of the same message (f.ex. PostScript and ASCII).
  310.  
  311.    The use of language tags to differentiate between different
  312.    alternatives will certainly not lead all MIME UAs to present the most
  313.    sensible body part as default.
  314.  
  315.    Therefore, a new parameter is defined, to allow the configuration of
  316.    MIME readers to handle language differences in a sensible manner.
  317.  
  318.     Name: Differences
  319.     Value: One or more of
  320.          Content-Type
  321.          Content-Language
  322.  
  323.    Further values can be registered with IANA; it must be the name of a
  324.    header for which a definition exists in a published RFC.  If not
  325.    present, Differences=Content-Type is assumed.
  326.  
  327.    The intent is that the MIME reader can look at these headers of the
  328.    message component to do an intelligent choice of what to present to
  329.    the user, based on knowledge about the user preferences and
  330.    capabilities.
  331.  
  332.    (The intent of having registration with IANA of the fields used in
  333.    this context is to maintain a list of usages that a mail UA may
  334.    expect to see, not to reject usages.)
  335.  
  336.  
  337.  
  338. Alvestrand                                                      [Page 6]
  339.  
  340. RFC 1766                      Language Tag                    March 1995
  341.  
  342.  
  343.    (NOTE: The MIME specification [RFC 1521], section 7.2, states that
  344.    headers not beginning with "Content-" are generally to be ignored in
  345.    body parts. People defining a header for use with "differences="
  346.    should take note of this.)
  347.  
  348.    The mechanism for deciding which body part to present is outside the
  349.    scope of this document.
  350.  
  351.     MIME EXAMPLE:
  352.  
  353.     Content-Type: multipart/alternative; differences=Content-Language;
  354.               boundary="limit"
  355.     Content-Language: en, fr, de
  356.  
  357.     --limit
  358.     Content-Language: fr
  359.  
  360.     Le renard brun et agile saute par dessus le chien paresseux
  361.     --limit
  362.     Content-Language: de
  363.     Content-Type: text/plain; charset=iso-8859-1
  364.     Content-Transfer-encoding: quoted-printable
  365.  
  366.     Der schnelle braune Fuchs h=FCpft =FCber den faulen Hund
  367.     --limit
  368.     Content-Language: en
  369.  
  370.     The quick brown fox jumps over the lazy dog
  371.     --limit--
  372.  
  373.    When composing a message, the choice of sequence may be somewhat
  374.    arbitrary. However, non-MIME mail readers will show the first body
  375.    part first, meaning that this should most likely be the language
  376.    understood by most of the recipients.
  377.  
  378. 5.  IANA registration procedure for language tags
  379.  
  380.    Any language tag must start with an existing tag, and extend it.
  381.  
  382.    This registration form should be used by anyone who wants to use a
  383.    language tag not defined by ISO or IANA.
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Alvestrand                                                      [Page 7]
  395.  
  396. RFC 1766                      Language Tag                    March 1995
  397.  
  398.  
  399. ----------------------------------------------------------------------
  400. LANGUAGE TAG REGISTRATION FORM
  401.  
  402. Name of requester          :
  403. E-mail address of requester:
  404. Tag to be registered       :
  405.  
  406. English name of language   :
  407.  
  408. Native name of language (transcribed into ASCII):
  409.  
  410. Reference to published description of the language (book or article):
  411. ----------------------------------------------------------------------
  412.  
  413.    The language form must be sent to <ietf-types@uninett.no> for a 2-
  414.    week review period before submitting it to IANA.  (This is an open
  415.    list. Requests to be added should be sent to <ietf-types-
  416.    request@uninett.no>.)
  417.  
  418.    When the two week period has passed, the language tag reviewer, who
  419.    is appointed by the IETF Applications Area Director, either forwards
  420.    the request to IANA@ISI.EDU, or rejects it because of significant
  421.    objections raised on the list.
  422.  
  423.    Decisions made by the reviewer may be appealed to the IESG.
  424.  
  425.    All registered forms are available online in the directory
  426.    ftp://ftp.isi.edu/in-notes/iana/assignments/languages/
  427.  
  428. 6.  Security Considerations
  429.  
  430.    Security issues are not discussed in this memo.
  431.  
  432. 7.  Character set considerations
  433.  
  434.    Codes may always be expressed using the US-ASCII character repertoire
  435.    (a-z), which is present in most character sets.
  436.  
  437.    The issue of deciding upon the rendering of a character set based on
  438.    the language tag is not addressed in this memo; however, it is
  439.    thought impossible to make such a decision correctly for all cases
  440.    unless means of switching language in the middle of a text are
  441.    defined (for example, a rendering engine that decides font based on
  442.    Japanese or Chinese language will fail to work when a mixed
  443.    Japanese-Chinese text is encountered)
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Alvestrand                                                      [Page 8]
  451.  
  452. RFC 1766                      Language Tag                    March 1995
  453.  
  454.  
  455. 8.  Acknowledgements
  456.  
  457.    This document has benefited from innumberable rounds of review and
  458.    comments in various fora of the IETF and the Internet working groups.
  459.    As so, any list of contributors is bound to be incomplete; please
  460.    regard the following as only a selection from the group of people who
  461.    have contributed to make this document what it is today.
  462.  
  463.    In alphabetical order:
  464.  
  465.    Tim Berners-Lee, Nathaniel Borenstein, Jim Conklin, Dave Crocker,
  466.    Ned Freed, Tim Goodwin, Olle Jarnefors, John Klensin, Keith Moore,
  467.    Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, and many, many
  468.    others.
  469.  
  470. 9.  Author's Address
  471.  
  472.    Harald Tveit Alvestrand
  473.    UNINETT
  474.    Pb. 6883 Elgeseter
  475.    N-7002 TRONDHEIM
  476.    NORWAY
  477.  
  478.    EMail: Harald.T.Alvestrand@uninett.no
  479.    Phone: +47 73 59 70 94
  480.  
  481. 10.  References
  482.  
  483.     [ISO 639]
  484.          ISO 639:1988 (E/F) - Code for the representation of names of
  485.          languages - The International Organization for
  486.          Standardization, 1st edition, 1988 17 pages Prepared by
  487.          ISO/TC 37 - Terminology (principles and coordination).
  488.  
  489.     [ISO 3166]
  490.          ISO 3166:1988 (E/F) - Codes for the representation of names
  491.          of countries - The International Organization for
  492.          Standardization, 3rd edition, 1988-08-15.
  493.  
  494.     [RFC 1521]
  495.          Borenstein, N., and N. Freed, "MIME Part One: Mechanisms for
  496.          Specifying and Describing the Format of Internet Message
  497.          Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
  498.  
  499.     [RFC 1327]
  500.          Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
  501.          822", RFC 1327, University College London, May 1992.
  502.  
  503.  
  504.  
  505.  
  506. Alvestrand                                                      [Page 9]
  507.  
  508.